1. Field of the Invention
The present invention relates in general to the exploitation of priority preemptive systems supporting Round-Robin scheduling policies and in particular to overcoming computational loses incurred during the concurrent execution of pooling and non-pooling algorithms. Still more particularly, the present invention relates to the automatic determination of a minimum useable user priority level. Finally, the present invention relates to a system and method for combining the concepts of recovered computational cycles and automatic minimum useable priority level with a visual display of the associated effective priority to an end user.
2. Description of the Prior Art
Early desktop computers employed a simple single tasking strategy as is the case with the Disk Operating System (DOS). Many applications that were written to run on this operating system were designed to consume every available computational cycle. This typically involved an infinite loop that would check for input from the keyboard or a communications port. This is commonly referred to as "pooling". It is generally accepted that no useful work is accomplished during pooling when no input is provided. Such would be the case when the user of the application pauses to think. As the development of operating systems designed to run on desktop computers evolved, many such applications could appear to run simultaneously by giving each application a small time slice of execution and running them one after another. This is referred to as "round-robin" scheduling. Modern desktop computer operating systems create a hierarchy of priority levels in which the highest priority schedulable unit is run ahead of all others. This is referred to as priority preemptive scheduling. In the event that there are two or more schedulable units of the same priority they will processed in a round-robin fashion. Applications that are written to run on priority preemptive operating systems are designed to voluntarily relinquish processor control after a specified time limit or in response to system events. These are referred to as "well behaved" applications. Operating systems are never aware of what the application will do and must handle all cases.
A problem presents itself when running the older DOS type pooling applications concurrently with the newer well behaved applications on a priority preemptive operating system such as IBM's OS/2. If the DOS type applications are higher in priority than the well behaved applications, then the well behaved applications will never get to run. If the well behaved applications are higher in priority than the DOS applications, then the DOS applications will only run when the well behaved applications relinquish the processor. The problem would be compounded when there are many well behaved applications such that they completely consume the processor bandwidth. In that event, the DOS applications would never get to run. OS/2 attempts solves this problem by utilizing a default priority level common to both the DOS type of applications and the well behaved applications. Additionally, complex set of controls governing the DOS application's processor consumption is provided. Since using these controls varies with the relative wide range of computing power available to desktop computers, the default levels are inherently suboptimal. Stated in another manner, by running both types of applications at the same priority level, there will be many processor cycles lost due to the pooling nature of the DOS applications. The problem intensifies when such applications are run on very fast computing machines such as the Intel i486 or Pentium processor. This is due to the fact that a small time slice of execution is given to each schedulable unit. In the case of an Intel i386DX 16 Mz machine given 32 milliseconds to execute the pooling loop it can safely be assumed that all computational cycles will be lost. Since an Intel i386DX 33 Mz machine is approximately twice as fast, twice the number of computational cycles will be lost. Since an Intel i486DX 33 Mz is again twice as fast, twice the number of computational cycles is lost again. Since an Intel i486DX 66 Mz machine is again approximately twice as fast, twice the number of computational cycles is lost again. Therefore, it is reasonable to assume that the computational looses of executing a pooling loop from a DOS type of application on an Intel i486DX 66 Mz machine is 8 times as great as the loses incurred on an Intel i386DX 16 Mz machine. Processors such as the Intel Pentium and future more powerful processors will be subjected to this phenomenon lost processor cycles to an even greater degree.
Priority preemptive operating systems containing many levels of priority typically employ a concept of foreground and background processing. Generally, there is a single foreground process which is higher in priority than all other processes which are the background processes. These background processes in many scenarios share the same priority level and thus are subjected to round-robin scheduling policies. In effect, this may result in a two level prioritization scheme regardless of the number of priority levels actually supported.
Scheduling policies are inherently tied to the memory management method. Intel processors i386 and beyond support virtualized memory management. This allows the operating systems to execute applications whose memory requirements exceed that of the actual physically configured memory. When a request for memory exceeds that of available memory, infrequently accessed portions of the programs in memory are rolled out to the hard disk. This will free the memory for the currently executing application. Code and data that is in memory can be accessed at the speed of the processor which is in the nanosecond range. Disk access in the millisecond range on roughly 1000 times slower. A problem presents itself when several applications require memory and are all run at the same priority class and level in a memory constrained environment. As the applications are loaded from the disk into memory, the physical memory becomes filled. Subsequent loading of more applications will cause more of the memory to rolled out to the disk. When the applications are each executed turn, its memory (code, data and stack segments) may be required to be rolled in from the disk. When the disk read is initiated to obtain a particular memory fragment, the application is queued on a waiting list and the next application is executed. In easily reproducible scenarios severe memory overcommitment may require days to complete, whereas the same application could complete in a matter of minutes in non-memory constrained environments. Consequently, the effects of round robin scheduling on virtualized memory management systems in memory overcommit scenarios is counterproductive.
Some Priority preemptive operating systems contain a concept of a scheduling class and level. Such is the case with IBM OS/2 and Microsoft NT operating systems. Programs can be subdivided into a specific class and further subdivided into various levels. High priority programs are generally placed into a time-critical class while the lowest priority programs are placed into an idle class. Operating system developers do not disclose the actual priority class and level at which any given application executes to the end user. However, a processor utilization chart, bar, or graph is common to priority preemptive systems. When the processor utilization tool shows 100% utilization, it is not known which class or level or combination of classes and levels are consuming all processor cycles. Should a user attempt to run an application that is lower in priority than the currently executing application or applications, the application will not execute. Currently, the application is selected to be the foreground process to increase its chances to execute. However, when placed in the background, the same application may not execute. Input from the keyboard and mouse requires the application to be the foreground process. Since the foreground is higher in priority than the background, the background only receives the processor cycles not needed by the foreground application. However, there are occasions when the user would desire to have the foreground priority less than the background. Such could be the case when a user wanted to run an important application ahead of simply perusing a data file. The point is that the user perceives the background application as very important and would accept a performance loss of perusing the data file. However, the act of perusing the data file would have the higher foreground priority. Currently, this scenario is not possible given the existing priority preemptive scheduling policies.
Therefore, it should be apparent that a need exists or a system and method to overcome the lost processor cycles due to concurrent execution of pooling and nonpooling applications, and providing a user selectable prioritization scheme to overcome the thrashing effects of Round-Robin scheduling in memory overcommit scenarios.